Dear Apple Team, As an MDM (Mobile Device Management) service provider, we are writing to bring attention to an issue that is affecting many of our customers who manage large fleets of iOS devices. Specifically, we have encountered challenges with the app update process via MDM, which is impacting both kiosk devices and non-kiosk devices in a variety of use cases. Issue 1: App Updates Delayed on Kiosk Devices Many of our customers are deploying kiosk devices that are used 24/7 independently with no attendants. In these cases, when an app update is sent through MDM via the installApplication command, the installation does not begin immediately. Instead, the update starts only after the device is locked. However, since these kiosk devices are running continuously, they are rarely locked, preventing the app update from occurring. To force the update, administrators need to manually remote lock or physically lock the device, which is a time-consuming process. This becomes even more challenging for devices like Apple TV, where remotely locking and unlocking the device to complete app updates is especially difficult, making it hard to keep the apps up to date in a timely manner. Issue 2: User Cancellations of Critical Updates on Non-Kiosk Devices In the case of non-kiosk devices, customers are encountering another challenge: when a critical update is pushed during business hours, users are often prompted to install the update. However, many users tend to cancel the update, leaving devices unpatched and potentially vulnerable. This behavior can delay the deployment of important security patches, which is a critical concern for organizations managing sensitive data or business-critical apps. Request for a Solution Our customers have expressed the need for a more reliable and forceful app update mechanism. Specifically, we are requesting the following features to improve the app update experience: Scheduled app updates: The ability to schedule app updates, similar to the way OS updates are handled. If the user does not install the update within a specified timeframe, the update should begin automatically or prompt the user with a stronger reminder. Force install option: A feature that would allow MDM administrators to force an app update immediately, without relying on user intervention. This would ensure that critical updates are installed promptly, improving security and system stability across all devices. These features are essential for many of our customers who rely on timely and consistent app updates to maintain security, functionality, and compliance across their managed devices. Without these options, they face challenges in ensuring devices are kept up-to-date, which can result in security vulnerabilities and operational disruptions. We kindly request that Apple consider adding these functionalities to improve the MDM app update process and provide a more reliable experience for both kiosk and non-kiosk device management. Thank you for your attention to this matter. We look forward to your feedback and any potential improvements in future iOS updates. Raised in the same manner as feedback: FB15910292

On a supervised device running iOS 18 without any AirDrop restrictions applied, when a profile with allowListedAppBundleIDs restriction key is installed, the AirDrop sound plays. But still the accept prompt does not appear, making it impossible to accept files. The prompt works as expected on iOS 18 devices to which the allowListedAppBundleIDs restriction is not installed. This issue occurs only on supervised iOS 18 devices to which the allowListedAppBundleIDs restriction is being applied. Device must be in iOS 18 version > Install the (allowListedAppBundleIDs restriction) profile with the device > Try to AirDrop files to the managed device. The expected result is that the accept prompt must pop up but it does not appear. This issue is occurring irrespective of any Whitelisted bundle ID being added to the allowListedAppBundleIDs restriction profile. Have attached a few Whitelisted bundle ID here com.talentlms.talentlms.ios.beta, com.maxaccel.safetrack, com.manageengine.mdm.iosagent, com.apple.weather, com.apple.mobilenotes, gov.dot.phmsa.erg2, com.apple.calculator, com.manageengine.mdm.iosagent, com.apple.webapp, com.apple.CoreCDPUI.localSecretPrompt etc. Have raised a Feedback request (FB15709399) with sysdiagnose logs and a short video on the issue.

I'm reaching out to discuss a significant issue related to how iOS handles app login sessions, particularly in the context of MDM (Mobile Device Management) and the Outlook app. In our organization, we use MDM to distribute applications, including Outlook, with certificate-based authentication for BYOD (Bring Your Own Device) devices. This setup allows users to log in seamlessly to their accounts. However, we've encountered a concerning behavior: when a user unenrolls from MDM, which automatically removes the distributed apps and certificates, they can later reinstall the app from the App Store and find themselves automatically logged back into their previous accounts without any authentication prompts. Here’s a detailed breakdown of the situation: Initial Installation: Users enroll their devices in MDM, which installs the necessary apps and certificates on those devices. Session Storage: After the initial login, the app stores the session locally on the device. App Deletion: When users un enroll their devices from MDM, it automatically removes the distributed apps and certificates. Reinstallation: Days or weeks later, when they reinstall the Outlook app from the App Store, they find themselves automatically logged back into their accounts. This behavior raises important concerns: Lack of Authentication: The app retaining user sessions even after deletion allows users to access their accounts without re-authentication, which could lead to potential unauthorized access and undermines the effectiveness of certificate-based authentication and two-factor authentication (2FA). Note: This issue is not limited to Outlook; we've observed similar behavior with many other apps. Need for a Solution - Given the implications of this behavior, we are looking for effective solutions to prevent it. Specifically, we need options within the MDM framework to: Restrict Session Retention: Implement settings that ensure any app deleted via MDM will lose all stored sessions and require re-authentication upon reinstallation. Default Settings for MDM-Distributed Apps: Ideally, this would be a default feature for all apps distributed through MDM, ensuring that user sessions are not retained after app deletion. Has anyone else experienced this issue? Are there any existing settings or workarounds within MDM platforms to mitigate this problem? Your insights and experiences would be invaluable as we navigate this challenge. Thank you!

Hi Apple Team , We have a. Bunch of macOS devices in our Fleet Which has MDM Passcode Payload Applied. We have observed a huge delay in unlocking the user account at login Screen after the Credentials are presented, Where as Removing the Passcode Payload makes the User to unlock their account at login Screen Immediately. Can someone help with this issue any OS Updates helps this ? Have Filed a FeedBack: FB15143190 (MDM Passcode Payload Causing Delay In Device Unlock) Also there is a Discussion reg this Passode Policy Issue

When syncing newly added or modified devices in the Apple Business Manager (ABM) portal using the POST request to https://mdmenrollment.apple.com/devices/sync, we are getting an issue when the ABM server account has more than 1000 devices. The response consistently includes 1000 devices, with the ‘more_to_follow’ flag always set to true and the ‘cursor’ value changing. However, subsequent ABM syncs for other devices result in duplicate devices being included in the response, and the ‘more_to_follow’ flag never becomes false. As more_to_follow is always true, we try to hit api continuously. Please refer this for sync API details which is causing issue: https://developer.apple.com/documentation/devicemanagement/sync_the_list_of_devices This issue appears to originate from the Apple ABM side. Any help would be of great use. Thanks in advance.

When making a GET request to the ABM Account API at https://mdmenrollment.apple.com/account, we receive a response that includes an org_email field. However, we’ve noticed that the value of org_email varies. Sometimes it corresponds to an account with the role of Administrator, while other times it comes from account with roles Device Enrolment Manager, Content Manager and People Manager. We seek clarification on the following points: Which roles determine the org_email sent in the response? Is the org_email coming in API response always same or does it change when we hit the APIs in multiple times. org_email in this response: https://developer.apple.com/documentation/devicemanagement/accountdetail

Enrol Supervised iOS device. Push an CardDAV policy for the above device, the contacts gets synced in the native Contacts app as expected. (https://developer.apple.com/documentation/devicemanagement/carddav) When the above same profile is re-installed in the above device, the synced contacts are lost and password prompt is shown to enter the password - even though the installed profile contains password for the CardDAV policy. Password prompt from the device Re-Installed configuration <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadUUID</key> <string>35ee541b-fec0-46b0-bd48-bcc0702ab60b</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadOrganization</key> <string>MDM</string> <key>PayloadIdentifier</key> <string>com.mdm.ec89620f-2905-4c14-b09d-7e9f17944468.CardDAV</string> <key>PayloadDisplayName</key> <string>CardDAV</string> <key>PayloadRemovalDisallowed</key> <true/> <key>PayloadContent</key> <array> <dict> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadUUID</key> <string>07c423b5-8ae2-4e6e-9336-aa9ca850d6c9</string> <key>PayloadType</key> <string>com.apple.carddav.account</string> <key>PayloadOrganization</key> <string>MDM</string> <key>PayloadIdentifier</key> <string>07cV423b5-8ae2-4e6e-9336-aa9ca850d6c9</string> <key>PayloadDisplayName</key> <string>CardDAV Policy</string> <key>CardDAVAccountDescription</key> <string>****</string> <key>CardDAVHostName</key> <string>www.googleapis.com</string> <key>CardDAVPassword</key> <string>****</string> <key>CardDAVPort</key> <integer>443</integer> <key>CardDAVPrincipalURL</key> <string></string> <key>CardDAVUseSSL</key> <true/> <key>CardDAVUsername</key> <string>****</string> </dict> </array> </dict> </plist> Feedback ID : FB14250521

Enrol Supervised iOS device Turn ON screen time restriction by opening Settings app -> Content & Privacy restrictions -> Passcode & Face ID -> Don’t Allow. Now install a Passcode policy profile via MDM with the key “forcePIN” set to “true”, such that the device is needed to change the passcode in device. By following above steps, the profile fails. The failure response from the device states that passcode restriction is applied in the device, “The profile ‘Profilename’ may require a passcode change but the passcode cannot be modified.” This is an incorrect behaviour as MDM should have more control over the screen-time restriction as well. Error response from the device <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CommandUUID</key> <string>InstallProfile</string> <key>ErrorChain</key> <array> <dict> <key>ErrorCode</key> <integer>4001</integer> <key>ErrorDomain</key> <string>MCInstallationErrorDomain</string> <key>LocalizedDescription</key> <string>Profile Installation Failed</string> <key>USEnglishDescription</key> <string>Profile Installation Failed</string> </dict> <dict> <key>ErrorCode</key> <integer>4026</integer> <key>ErrorDomain</key> <string>MCInstallationErrorDomain</string> <key>LocalizedDescription</key> <string>The profile **** may require a passcode change but the passcode cannot be modified.</string> <key>USEnglishDescription</key> <string>The profile **** may require a passcode change but the passcode cannot be modified.</string> </dict> </array> <key>Status</key> <string>Error</string> <key>UDID</key> <string>****</string> </dict> </plist> Feedback ID : FB14249704

Enroll an iOS device via MDM and apply passcode policy with "maxFailedAttempts" setting enabled https://developer.apple.com/documentation/devicemanagement/passcode Now when the user attempts to unlock device exceeds above "maxFailedAttempts" - the device gets wiped. Now the administrator is unaware of this event. It would be helpful to get an message/DDM status from device to notify the MDM server that device is wiped due to incorrect passcode attempts.

In the case of organizational iPad devices, we need to have them in a more organized way via the homescreenlayout payload. We need to control the dock and the app library. We will be allowing certain apps on the device via allowListedAppBundleIDs, so we want to disable the recent apps in the dock and prevent apps from being duplicated in the app library, including recent apps and Siri suggestions. If there are more options to control the complete screen layout on the device, it would be helpful.

https://developer.apple.com/documentation/devicemanagement/systempreferences The Above documentation of "System Preferences" says deprecated. I assume that some of the panes are not working in latest OS due to this deprecation. My query is , Is there any other alternative to Disable or Enabled Preference Panes which was attained by SystemPreferences Payload. I couldn't find any. Is it entirely stopped and in latest OS's ,it wont allowed to restrict those panes?

Hi, We have our devices listed in Apple Business Manager but they are not enrolled in MDM. Some of the devices are locked in Activation Lock screen as employees logged in with their personal account . Since devices are company owned and already available in ABM is there any way to remove activation lock easily without providing proof of purchase to apple? In order to prevent devices getting into activation lock in future the only way is to Enroll the device in a MDM? Are there anyways to bypass activation lock if we are not using MDM

Hi all , We are planning to manage about 1 Million+ Apple devices of inclusive of both iPhone and Mac devices under a AxM Account. However while adding VPP Licenses for an App i'm prompted with below error: " You cannot order more than 100000 copies of same the free item per week" While our goal is to manage 1 Million devices under same Location token , i have below questions in mind 1 . What is the upper limit of number of Licenses that can be added per app in a Location token? Currently it says 1 Lakh Licenses per app per week . Wanted to know if there is any limit on this count as it shouldn't surprise us in upcoming weeks. 2 . How many Locations can be created in a AxM Account? Currently we created about 15 location to see if there are any limit but so far couldn't find any limit on number of locations that can be created. This limit could help us plan our deployment in advance 3 . What is the total number of licenses a VPP Location token can hold ? As we manage 1 Million Devices for 12 Apps , 1 Million x 12= 12 Million licenses would be transacted in this location token by our MDM Solution , is this okay or will there be any limitations in this count

In older versions of macOS, such as those predating Mac OS Sonoma, users had the ability to set the Lock Screen independently from their desktop wallpaper. However, with the introduction of Mac OS Sonoma, this feature seems to have been altered or removed altogether. Currently, there appears to be no option to set the Lock Screen image separately; instead, only changing the desktop wallpaper, changes the Lock Screen image. This change raises questions about whether it is a deliberate alteration in the setting flow or if it could potentially be a bug in the system. Users may wonder if this adjustment is intended to streamline the interface or if there are plans to reintroduce the ability to customize the Lock Screen image independently of the wallpaper in future updates.

I have tried to deploy passwordpolicy script using pwpolicy pwpolicy -n /Local/Default -setglobalpolicy "usingHistory=5 canModifyPasswordforSelf=1 maxMinutesUntilChangePassword=129600 requiresAlpha=1 requiresNumeric=1 minChars=8 passwordCannotBeName=1 requiresMixedCase=1 requiresSymbol=1" sudo defaults write /Library/Preferences/com.apple.loginwindow PasswordExpirationDays 14 errcode=$? if [ "$errcode" -ne 0 ]; then echo "" echo "Failed to apply with errorcode $errcode" 1>&2 echo "" exit 1 fi echo "Password Policy applied successfully" 1>&2 After deploying, on next login, It prompted for login, On entering password, It shows wrong password. When I tried to reset the password, It is not accepting the password. Instead It prompts again and again. Like this , I have got 300 mac machines struck in login page. I tried to run these two commands via a app running in root pwpolicy -u "$user" -clearaccountpolicies pwpolicy -clearaccountpolicies After Running this, I can able to loggin for first time. When tried to login second or successive times, It is failing with wrong password or sometimes no error instead of a jumping prompt in password page. When tried to change password after a login after clearpolicy command, It is not accepting the admin's password (Which was used to login the current session). Please help on this issue. As it does have a serious impact.